@anoek, this function expected_win_probability shows up in other repos, with the same bug, but aside from unit tests it doesn't seem to be USED by anything (except prediction_cost in this, the goratings repo).

Let me know if/when to send out parallel PRs. Personally I'd be tempted to delete it from the other repos since it's not used there but up to you.

Ah, so the source of confusion is that this function is using the original glicko expected outcome formula on page 5 of http://www.glicko.net/glicko/glicko.pdf , as opposed to from http://glicko.net/glicko/glicko2.pdf

The original formula was this:

so that's where the 10** and / 400 come from

Note that the actual glicko2 implementation uses the E as defined by the glicko2 paper, this method was just used for that predicted outcome tally.

I'm guessing what happened is I did the original implemenation, came back to it a year or two later, thought "Hey I want to look at the estimated outcome", searched the glicko2 paper and didn't find the keywords I wanted and didn't pause long enough to think about the math, meanwhile the original glicko paper had a function that sounded like what I wanted, and given my understanding that glicko and glicko2 are completely compatible with one another, just glicko2 updates faster/better, I probably said to myself, this should work just fine for crunching some simple analytics. And I assume it does, though I assume using E from the glicko2 paper would be an improvement.

@anoek, this function expected_win_probability shows up in other repos, with the same bug, but aside from unit tests it doesn't seem to be USED by anything (except prediction_cost in this, the goratings repo).

Let me know if/when to send out parallel PRs. Personally I'd be tempted to delete it from the other repos since it's not used there but up to you.

Yeah I reckon eliminating it is probably a good thing. Honestly I don't know that it's useful here either, it's not immediately obvious to me whether using the value like we do produces anything meaningful. Seems like if we do keep it, we should update it though.

@anoek, this function expected_win_probability shows up in other repos, with the same bug, but aside from unit tests it doesn't seem to be USED by anything (except prediction_cost in this, the goratings repo).
Let me know if/when to send out parallel PRs. Personally I'd be tempted to delete it from the other repos since it's not used there but up to you.

Yeah I reckon eliminating it is probably a good thing. Honestly I don't know that it's useful here either, it's not immediately obvious to me whether using the value like we do produces anything meaningful. Seems like if we do keep it, we should update it though.

Well, it's used in goratings to compute the prediction_cost, which is the main thing you look at, so we can't eliminate it here...

Ah, so the source of confusion is that this function is using the original glicko expected outcome formula on page 5 of http://www.glicko.net/glicko/glicko.pdf , as opposed to from http://glicko.net/glicko/glicko2.pdf

The original formula was this:

so that's where the 10** and / 400 come from

Note that the actual glicko2 implementation uses the E as defined by the glicko2 paper, this method was just used for that predicted outcome tally.

I'm guessing what happened is I did the original implemenation, came back to it a year or two later, thought "Hey I want to look at the estimated outcome", searched the glicko2 paper and didn't find the keywords I wanted and didn't pause long enough to think about the math, meanwhile the original glicko paper had a function that sounded like what I wanted, and given my understanding that glicko and glicko2 are completely compatible with one another, just glicko2 updates faster/better, I probably said to myself, this should work just fine for crunching some simple analytics. And I assume it does, though I assume using E from the glicko2 paper would be an improvement.

Aha. I should update it more fully then before pushing. I'll make this a draft for now.

Well, it's used in goratings to compute the prediction_cost, which is the main thing you look at, so we can't eliminate it here...

It's not though, the main thing I was looking at was the handicap stuff at the top, it's all about those black win rates being consistent - if you've those pegged then it means your rating to ranking map is good. Everything else is just to help validate what I was seeing, maybe develop some further intuitions, that sort of stuff. So in that regard, sure might as well update it, but the main thing is optimizing for ensuring that if we have a rank difference between players, that corresponds directly to how much of a handicap they should have.

Well, it's used in goratings to compute the prediction_cost, which is the main thing you look at, so we can't eliminate it here...

It's not though, the main thing I was looking at was the handicap stuff at the top, it's all about those black win rates being consistent - if you've those pegged then it means your rating to ranking map is good. Everything else is just to help validate what I was seeing, maybe develop some further intuitions, that sort of stuff. So in that regard, sure might as well update it, but the main thing is optimizing for ensuring that if we have a rank difference between players, that corresponds directly to how much of a handicap they should have.

Oh, the black win rate. I misunderstood which table you were looking at :/. (My fault... you did say the FIRST table, but I somehow was looking at the second.)

I think cc296a6 updates it correctly / the rest of the way. This makes the math domain error come back... so now I'm not sure it really makes a difference.

Effectively replaced this with #57 for now.

I think cc296a6 updates it correctly / the rest of the way. This makes the math domain error come back... so now I'm not sure it really makes a difference.

I'm going to close this one and re-open a clean PR to consider.